Software Project Management

The Cleanroom software developmentThis paper is a report of an application of the meth-approach is intended to produce highly reliableod described in [Albrecht83].software by integrating formal methods for specification and design, nonexecution-based program de-Berger85velopment, and statistically based independent testing. In an empirical study, 15 three-person teamsBerger, J. O. Statistical Decision Theory anddeveloped versions of the same software system Bayesian Analysis, 2nd Ed. New York: Springer-(800-2300 source lines); ten teams applied CleanVerlag, 1985.room, while five applied a more traditional ap-Covers the foundations and concepts of statisticalproach. This analysis characterizes the effect ofdecision theory, including situations where data areCleanroom on the delivered product, the softwareincomplete. This book approaches statistics fromdevelopment process, and the developers.the business perspective where not all of the dataThe major results of this study are the following. 1)are available. It introduces the probability of ac-Most of the developers were able to apply the tech-curacy of the data into the statistical calculations,niques of Cleanroom effectively (six of the tenstatistics based on probable accuracy of the dataCleanroom teams delivered at least 91 percent of(Bayesian), is not appreciated by the mathematicalthe required system functions). 2) The Cleanroomapproach to statistics.teams’ products met system requirements more completely and had a higher percentage of success-Bernstein81ful operationally generated test cases. 3) The source code developed using Cleanroom had moreBernstein, L. “Software Project Managementcomments and less dense control-flow complexity. Audits.” J. Syst. and Software 2, 4 (Dec. 1981),4) The more successful Cleanroom developers mod281-287.ified their use of the implementation language; theyAbstract: This paper shows how project audits canused more procedure calls and IF statements, usedbe used to uncover project strengths andfewer CASE and WHILE statements, and had aweaknesses. Three audits are described and find-lower frequency of variable reuse (average numberings of the audit teams are summarized. Auditsof occurrences per variable). 5) All ten Cleanroomhelped identify organizational problems, lackingteams made all of their scheduled intermediatemanagement discipline, and software testing ap-product deliveries, while only two of the five non-proaches useful to other projects. The issue ofCleanroom teams did. 6) Although 86 percent ofproduct sales versus disciplined project manage-the Cleanroom developers indicated that theyment was faced in all three audits. How this issuemissed the satisfaction of program execution towas handled is discussed and related to the successsome extent, this had no relation to the productor lack of it for each project.quality measures of implementation completeness and successful operational tests. 7) Eighty-one per-This paper illustrates one method of status evalu-cent of the Cleanroom developers said that theyation.would use the approach again. This paper can be used to illustrate quality-based Bersoff80life cycles.Bersoff, E. H., V. D. Henderson, and S. G. Siegel.Software Configuration Management. EnglewoodCliffs, N.J.: Prentice-Hall, 1980. 16Draft For Public ReviewSEI-CM-21-1.0 Software Project Management field of software cost estimation, including theThis book contains the most complete description ofmajor estimation techniques available, the state ofsoftware configuration management available. Itthe art in algorithmic cost models, and the out-provides a fairly complete rationale for what to dostanding research issues in software cost estima-and why. The authors have their own conceptualtion.breakdown of the subject that does not map one-for-one onto the organization of this module. The bookThis is a short summary of the thesis of [Boehm81].also does not clearly explain how to perform config-uration management tasks.Boehm84b Boehm, Barry W., Terence E. Gray, and ThomasBersoff84Seewaldt. “Prototyping Versus Specifying: A Mul-Bersoff, Edward H. “Elements of Software Configu-tiproject Experiment.” IEEE Trans. Software Eng.ration Management.” IEEE Trans. Software Eng.SE-10, 3 (May 1984), 290-302.SE-10, 1 (Jan. 1984), 79-87. Abstract: In this experiment, seven software teamsAbstract: Software configuration managementdeveloped versions of the same small-size (2000-(SCM) is one of the disciplines of the 1980’s which4000 source instruction) application software prod-grew in response to the many failures of the soft-uct. Four teams used the Specifying approach.ware industry throughout the 1970’s. Over the lastThree teams used the Prototyping approach.ten years, computers have been applied to the soluIn this experiment, seven software teamsAbstract: Software configuration managementdeveloped versions of the same small-size (2000-(SCM) is one of the disciplines of the 1980’s which4000 source instruction) application software prod-grew in response to the many failures of the soft-uct. Four teams used the Specifying approach.ware industry throughout the 1970’s. Over the lastThree teams used the Prototyping approach.ten years, computers have been applied to the solution of so many complex problems that our ability toThe main results of the experiment were the follow-manage these applications has all too frequentlying.failed. This has resulted in the development of a1) Prototyping yielded products with roughlyseries of “new” disciplines intended to help controlequivalent performance, but with about 40the software process.percent less code and 45 percent less effort.This paper will focus on the discipline of SCM by first placing it in its proper context with respect to2) The prototyped products rated somewhatthe rest of the software development process, aslower on functionality and robustness, butwell as to the goals of that process. It will examinehigher on ease of use and ease of learning.the constituent components of SCM, dwelling at3) Specifying produced more coherent de-some length on one of those components, configu-signs and software that was easier to inte-ration control. It will conclude with a look at whatgrate.the 1980’s might have in store.The paper presents the experimental data support-This paper is good background reading for a lectureing these and a number of additional conclusions.on SCM.This paper provides an example of an alternativedevelopment cycle.Boehm81 Boehm, Barry W. Software Engineering Economics.Boehm87Englewood Cliffs, N.J.: Prentice-Hall, 1981.Boehm, Barry W. “Improving Software Productiv-This book must be read by every teacher or potenity.” Computer 20, 9 (Sept. 1987), 43-57.tial teacher of project management. Since economicThis article is an excellent short summary of thematters are intricately involved in most aspects ofrealistic factors involved in increasing the produc-software project management, the bulk of this booktivity of software developers. Boehm’s explicitis usable in a course on that subject. Chapters 1-3belief is that the quality of management is the mostand 33 should be read first, followed by 4-9. Theseimportant factor in the success of a project. Anchapters provide basic background knowledge es-extensive selected bibliography by productivity fac-sential to every project management teacher.tor (“getting the best from people,” “eliminatingrework,” etc.) is included.Boehm84a Boehm, Barry W. “Software Engineering Econom-Boehm88ics.” IEEE Trans. Software Eng. SE-10, 1 (Jan.Boehm, Barry W. “A Spiral Model of Software De-1984), 4-21.velopment and Enhancement.” Computer 21, 5 (MayAbstract: This paper summarizes the current state 1988), 61-72.of the art and recent trends in software engineeringYet another example of a risk-reduction life cycle.economics. It provides an overview of economic analysis techniques and their applicability to software engineering and management. It surveys the SEI-CM-21-1.0Draft For Public Review17 Software Project Management ing functions geared to maintaining delivered soft-Branstad84ware are described. The suggested software man-Branstad, Martha, and Patricia B. Powell. “Softwareagement practices result from the experience of aEngineering Project Standards.” IEEE Trans. Soft-small (approximately 100 employees) software en-ware Eng. SE-10, 1 (Jan. 1984), 73-78.gineering company that develops and maintains computer systems supporting real-time interactiveAbstract: Software Engineering Project Standardscommercial, industrial, and military applications.(SEPS) and their importance are presented in this paper by looking at standards in general, thenThis paper can be used as an illustration of alter-progressively narrowing the view to software stan-native quality assurance techniques.dards, to software engineering standards, and finally to SEPS. After defining SEPS, issues associ-Buckley84ated with the selection, support, and use of SEPS are examined and trends are discussed. A brief Buckley, Fletcher J., and Robert Poston. “Softwareoverview of existing software engineering standards Quality Assurance.” IEEE Trans. Software Eng.is presented as the Appendix.SE-10, 1 (Jan. 1984), 36-41. This paper is useful as an overview if no specificAbstract: This paper describes the status of soft-standard is used in class.ware quality assurance as a relatively new and autonomous field. The history of its development from hardware quality assurance programs is dis-Brooks75cussed, current methods are reviewed, and futureBrooks, Frederick. The Mythical Man-Month: Es-directions are indicated.says on Software Engineering. Reading, Mass.:Addison-Wesley, 1975. The book was “reprintedThis paper provides useful information for introduc-with corrections” in January 1982.ing quality assurance. Brooks wrote a true classic in the field of softwareCave78engineering. Most of the text can be mined forCave, William C., and Alan B. Salisbury.management advice, as it is a “lessons learned” doc-ument of Brooks’s career with IBM.“Controlling the Software Life Cycle—The ProjectManagement Task.” IEEE Trans. Software Eng.SE-4, 4 (July 1978), 326-334.Brooks87 Brooks, Frederick P., Jr. “No Silver Bullet: EssenceAbstract: This paper describes project manage-and Accidents of Software Engineering.” Computerment methods used for controlling the life cycle of24, 4 (April 1987), 10-19.large-scale software systems deployed in multiple installations over a wide geographic area. A set ofIn this article Brooks discusses why software isn’tmanagement milestones is offered along with re-improving by leaps and bounds like hardware, whyquirements and techniques for establishing andit never will, and what it takes to get the most out ofmaintaining control of the project. In particular, asoftware development.quantitative measure of software quality is proposed based upon functional value, availability, andBryan84maintenance costs. Conclusions drawn are based on the study of several cases and are generally ap-Bryan, William, and Stanley Siegel. “Making Soft-plicable to both commercial and military systems.ware Visible, Operational, and Maintainable in aSmall Project Environment.” IEEE Trans. SoftwareThis paper is a useful overview of the tools, tech-Eng. SE-10, 1 (Jan. 1984), 59-67.niques, and approaches to managing software devel-opment.Abstract: Practical suggestions are presented for effectively managing software development in small-project environments (i.e., no more than sev-Chisum86eral million dollars per year). The suggestions are Chisum, Donald S. “The Patentability of Algo-based on an approach to product development rithms.” U. of Pittsburgh Law Review 47, 4 (Sum-using a product assurance group that is independmer 1986), 959-1022.ent from the development group. Within this checkand-balance management/development/product as-Abstract: In this Article, the author argues thatsurance structure, a design review process is de-algorithms, which are sets of specific rules for solv-scribed that effects an orderly transition from cus-ing a mathematical or other type of problem andtomer needs statement to software code. The testingwhich are highly useful as the backbones of com-activity that follows this process is then explained.puter programs, should be the subject of patent pro-Finally, the activities of a change control bodytection if the patent law standards of novelty and(called a configuration control board) and support-unobviousness are met. After discussing case law 18Draft For Public ReviewSEI-CM-21-1.0 Software Project Management developments prior to 1972, the author analyzesmetrics and models usable in software engineeringand criticizes the Supreme Court decision inavailable. For project management, chapters 1, 2, 5,Gottschalk v. Benson, which held that mathematical6, 7, and 8 are most useful, but every project man-algorithms were unpatentable per se as laws of na-ager and instructor will need this book in his or herture or mere ideas. He argues that the Benson rulelibrary.is unsupported by statute or case law authority or by policy considerations. He then analyzes the Cooper78post-Benson Supreme Court decisions in Parker v.Cooper, John D. “Corporate Level Software Man-Flook, which extended Benson, and Diamond v.agement.” IEEE Trans. Software Eng. SE-4, 4 (JulyDiehr, which restricted it, and four 1982 decisions1978), 319.by the Court of Customs and Patent Appeals. He shows that theses cases fail to provide clearAbstract: Software management is considered fromguidance on what types of algorithms may bethe corporate headquarters viewpoint. This per-patented as processes or methods. He contends thatspective encompasses all facets of management, butBenson is inconsistent in philosophy with thespecifically dealt with are those that are brought toSupreme Court’s 1980 decision in Diamond v.bear on software management obstacles and waysChakrabarty, which held that genetically alteredto cope with them are presented. Standardization ismicroorganisms may be patented and stressed thatpresented as the most effective management devicenew technological developments covered by theavailable at the corporate level for enhancing thegeneral terms of the patent statute should be in-overall software posture. Corporate managementcluded in the patent system unless specifically ex-actions available for favorably influencing the qual-cluded by Congress. The author concludes thatity of software over its life cycle and research initia-patent protection for algorithms may be needed totives are described.provide incentives for innovation in software development as a supplement to copyright and tradeThis is a much needed article addressing softwaresecret protection of computer programs since themanagement from the “other side” of the softwarelatter two forms of protection do not protect againstdevelopment environment. Problems unique tounauthorized copying of publicly-disclosed ideas. Asoftware management are presented.“computer scientist’s response” on the issue of patentability and algorithms, by Professor Allen Cooper84Newell of Carnegie Mellon University, follows thisCooper, Jack. “Software Development ManagementArticle.Planning.” IEEE Trans. Software Eng. SE-10, 1This paper discusses the legal history of software, (Jan. 1984), 22-26.as well as the problems encountered in categorizingAbstract: The lack of comprehensive planning pri-software for legal protection purposes.or to the initiation of a software development project is a very pervasive failing. This paper walksClark38through a sample software development plan dis-Clark, W. The Gantt Chart. London: Sir Isaac Pit-cussing the various areas that a software develop-man & Sons, 1938.ment manager should address in preparing his project’s plan. Various considerations and sugges-This book describes the various uses of bar chartstions are presented for each of the managementfollowing the ideas of Henry Gantt.subject areas. How the user/customer can use the developer’s plan to aid in monitoring of hisCollofello87software’s evolution is also presented. Detailed planning of a software development project is nec-Collofello, James S., and Jeffrey J. Buck. “Softwareessary to the successful completion of the project.Quality Assurance for Maintenance.” IEEE Software4, 9 (Sept. 1987), 46-51.The step-by-step analysis of a sample software development plan in this paper forces many details toCollofello and Buck provide some insight on man-light that are ignored by other authors.aging a project for prevention of software problems,as well as correction of problems through software quality assurance.Cori85 Cori, Kent A. “Fundamentals of Master SchedulingConte86for the Project Manager.” Project ManagementJ. 16, 2 (June 1985), 78-89.Conte, S. D., H. E. Dunsmore, and V. Y. Shen.Software Engineering Metrics and Models. MenloThis article outlines the functions and responsibil-Park, Calif.: Benjamin/Cummings, 1986.ities of the project manager and surveys five different scheduling techniques. The material on miles-This is the single most complete treatment oftones is particularly useful. SEI-CM-21-1.0Draft For Public Review19 Software Project Management Cottrell86Cyert87 Cottrell, Paul, and James Maron. “Professional Cyert, R. M. Bayesian Analysis and Uncertainty inLiability for Computer Design.” The Computer Economic Theory. Totowa, N.J.: Rowman & Lit-Lawyer 3, 8 (Aug. 1986), 14-20.tlefield, 1987. This is a discussion of legal liability and responsi-Looks at statistical methods used in economicsbility for the computer industry.where data are incomplete. Crawford85Dart87 Crawford, Stewart G., and M. Hosein Fallah. Dart, Susan A., Robert J. Ellison, Peter H. Feiler,“Software Development Process Audits—A General and Nico Habermann. “Software Development En-Procedure.” Proc. 8th Intl. Conf. on Software vironments.” Computer 20, 11 (Nov. 1987), 18-28.Engineering. Washington, D.C.: IEEE ComputerThis taxonomy of software development environ-Society Press, 1985, 137-141.ments serves as useful reading for discussions ofresource acquisition, allocation, and training.Abstract: To assist development organizations in improving software quality and productivity, the AT&T; Bell Laboratories Quality Assurance Center DeMarco82created a Design Quality Group to independently DeMarco, Tom. Controlling Software Projects. Newevaluate the software development processes and York: Yourdon Press, 1982.associated development products of our AT&T; projects. These software development process auditsThis book concentrates heavily on metrics and theexamine software engineering techniques and toolsexamination of quality factors as the basis for man-in practice, as they fit into the overall developmentagement of software projects. Essentially, DeMarcoenvironment. Our strategy behind these audits is tomakes the case that you cannot control what youassemble a team which, with the involvement of thecannot measure. Useful for finding ways to inte-developers and their managers, will: characterizegrate metrics into an organization.the existing development process; identify project strengths and areas for improvements; and recomDeMarco87mend possible improvements. This paper details theDeMarco, Tom and Timothy Lister. Peopleware:general approach behind this strategy.Productive Projects and Teams. New York: DorsetThis is a good example for discussing the pros and House, 1987.cons of having an external quality assurance group.A collection of essays on managing projects and thepeople who carry them out by a pair of authors withCupello88substantial project management and consulting ex-Cupello, James M., and David J. Mishelevich.perience. The essays challenge conventional man-“Managing Prototype Knowledge/Expert Systemagement wisdom and emphasize how creating theProjects.” Comm. ACM 31, 5 (May 1988), 534-541.right work environment can increase productivity. Fundamental issues of technology transfer, training,Deming86problem selection, staffing, corporate politics, and more, are explored.Deming, W. Edwards. Out of the Crisis. Cambridge,Mass.: MIT Center for Advanced EngineeringStudy, 1986.Curtis88 Curtis, Bill, Herb Krasner, and Neil Iscoe. “A FieldDeming advocates the transformation of AmericanStudy of the Software Design Process for Largemanagement to focus on increasing quality andSystems.” Comm. ACM 31, 11 (Nov. 1988),productivity within organizations. He offers 141268-1287.guiding principles for achieving this transformation, and he identifies the “deadly diseases” andA rare study of how software development reallyobstacles that currently are barriers to doing so.takes place. The authors interviewed personnelDeming’s principles provided the framework for thefrom 17 large software projects. Using a layereddevelopment of postwar Japanese industry, and hebehavioral model, they analyze the impact on qual-is widely credited with guiding its tremendous suc-ity and productivity of shifting requirements, inade-cess.quate domain knowledge, and communication prob-lems. 20Draft For Public ReviewSEI-CM-21-1.0 Software Project Management management, etc.). One of the best parts of thisDoD88guide is the conceptual introduction to the softwareDoD. Military Standard for Defense System Soft-development process and the relation of the projectware Development. DOD-STD-2167A, U. S. De-plan to it.partment of Defense, Washington, D.C., 29 February1988.Feller68Due to its completeness and maturity as the succesFeller, W. An Introduction to Probability Theorysor to military standards of the preceding two and Its Applications, 3rd Ed. New York: Johndecades, this is one of the best available examples Wiley, 1967.to use when discussing standards. This book is used to teach probability and statisticsusing a mathematical approach.EPOS88 EPOS. SPS, Inc., New York, 1988.Ferrari78A comprehensive software engineering environment Ferrari, D. Computer Systems Performance Evalu-for workstations that includes project managementation. Englewood Cliffs, N.J.: Prentice-Hall, 1978.tools. This book looks at performance evaluation usingmeasurement, simulation, and analytic techniques.Evans83It then applies these to solve problems characteristicEvans, M. W., P. H. Piazza, and J. B. Dolkas.of methodology selection, design alternatives, andPrinciples of Productive Software Management.product improvement.New York: John Wiley, 1983. This book describes a methodology for software Freeman87management and the associated control techniques Freeman, Peter. Software Perspectives: The Systemfor the entire development process, as practiced by is the Message. Reading, Mass.: Addison-Wesley,the authors at Ford Aerospace and Communications1987.Corporation and several other companies. This book is too general to be a single text for soft-ware project management courses. However, itFagan76does emphasize the importance of environments andFagan, M. “Design and Code Inspections to Reducepreparing for transition of a product.Errors in Program Development.” IBM SystemsJ. 15, 3 (1976), 182-211.Friedman87A “must read” classic paper that introduces the Friedman, Marc S., and Mary J. Hildebrand.whole concept of software inspections. Sample “Computer Litigation: A Buyer’s Theories offorms, checklists, and experimental data from IBMLiability.” The Computer Lawyer 4, 12 (Dec. 1987),are also presented.34-38. This article provides useful material for a discussionFairley85of software users’ rights and responsibilities.Fairley, Richard E. Software Engineering Concepts.New York: McGraw-Hill, 1985.Gilb88Of the plethora of introductory texts on softwareGilb, Tom. Principles of Software Engineeringengineering, Fairley’s has, arguably, the best set ofManagement. Reading, Mass.: Addison-Wesley,references. His text is compact, living up to the title1988.in that only “concepts” are presented; but extensivereferences are given for each topic. The first threeGilb has written a nearly complete discussion ofchapters are most useful in the management area.project management from a unique viewpoint. Fairley88Glass81Fairley, Richard E. “A Guide to Preparing Software Glass, Robert L., and Ronald A. Noiseux. SoftwareProject Management Plans.” In Tutorial: Software Maintenance Guidebook. Englewood Cliffs, N.J.:Engineering Project Management, Richard Prentice-Hall, 1981.H. Thayer, ed. Washington, D.C.: IEEE ComputerThis book is useful for background on managingSociety Press, 1988, 257-264.maintenance.This is written in the spirit of the various IEEE stan-dards for plans (quality assurance, configuration SEI-CM-21-1.0Draft For Public Review21 Software Project Management Gourd82Humphrey87 Gourd, Roger S. “Self-Assessment Procedure X: A Humphrey, Watts S. Managing for Innovation:Self-Assessment Procedure Dealing with Software Leading Technical People. Englewood Cliffs, N.J.:Project Management.” Comm. ACM 25, 12 (Dec. Prentice-Hall, 1987.1982), 883-887.If there is a Mythical Man-Month for managers, thisis probably it. Humphrey has collected his and hisSelf-assessments are a familiar but irregular featureIBM colleagues’ collective experiences in leadingof the Communications of the ACM. This one istechnical individuals and teams into this compact,weaker than some, being most useful for beginnersreadable, and immediately useful book. It is best toto the subject, helping to identify which buzzwordread a chapter at a time, with some reflection be-categories are most in need of development.tween segments—there is just too much in a typicalchapter to absorb it adequately in conjunction withHarvey86its neighbors.Harvey, Katherine E. Summary of the SEI Workshopon Software Configuration Management. CMU/Humphrey88SEI-86-TR-5, Software Engineering Institute, Pitts-Humphrey, Watts S. “Characterizing the Softwareburgh, Pa., Dec. 1986.Process: A Maturity Framework.” IEEE Software 5,This is good reference material for presenting basic 3 (March 1988), 73-79.concepts on configuration management.Humphrey presents a framework for the evolutionof the software development process.Holmes82 Holmes, Robert A. “Application of Article Two ofHumphrey89the Uniform Commercial Code to Computer SystemHumphrey, Watts S. Managing the SoftwareAcquisitions.” Rutgers Computer and TechnologyProcess. Reading, Mass.: Addison-Wesley, 1989.Law J. 9, 1 ( 1982), 1-26. A genuine handbook for managers. It is very de-This article address such issues as product misrepre-tailed and complete.sentation, purchasing of systems, warranties, andunconscionability.IBM85 Issue on Quality and Productivity. G. M. Gershon,Howes84ed. IBM Systems J. 24, 2 (1985).Howes, Norman R. “Managing Software Develop-ment Projects for Maximum Productivity.” IEEEThis issue is devoted to articles concerned with soft-Trans. Software Eng. SE-10, 1 (Jan. 1984), 27-35.ware quality and productivity. It concentrates pri-marily on the development of large systems andAbstract: In the area of software development, datacontains measurements of organizations thatprocessing management often focuses more on“produce several million lines of new and changedcoding techniques and system architecture than oncode every year.” It contains articles on program-how to manage the development. In recent years,ming process, automation of the development proc-“structured programming” and “structured analy-ess, software methodologies, defect prevention ap-sis” have received more attention than the tech-proaches, software engineering education, andniques software managers employ to manage.productivity measurements. It contains a lot ofMoreover, these coding and architectural con-metrics and analyses of the effectiveness of differ-siderations are often advanced as the key to aent approaches.smooth running, well managed project. This paper documents a philosophy for software deIEEE83velopment and the tools used to support it. ThoseIEEE. IEEE Standard Glossary of Software Engi-management techniques deal with quantifying suchneering Terminology. New York: IEEE, 1983.abstract terms as “productivity,” “performance,”ANSI/IEEE Std 729-1983.and “progress,” and with measuring these quantities and applying management controls to maximize them. The paper also documents the application of IEEE84these techniques on a major software development IEEE. IEEE Standard for Software Quality As-effort.surance Plans. New York: IEEE, 1984. ANSI/Howes suggests a method for “packing” work, and IEEE Std 730-1984.details the components involved in planning, ex-ecuting, and evaluating the software development